test: resolve challenge records through the mock, and check that it happened - #1144

Problem

certbot resolves each challenge name itself before telling the CA to go and
look, so a record that has not propagated is reported by name instead of as an
order failure. The E2E suite never exercised it.

The gateway resolved through Docker's embedded DNS, which has never heard of
the test zones. So every self-check ran its full budget, warned, and proceeded
— for dns-01 too, seconds after certbot itself had written the record
through the mock's Cloudflare API:

WARN  no authoritative nameserver for _acme-challenge.test0.local,
      using the system resolver
DEBUG challenge not found, waiting for 500ms  tries=2  max_wait=30s
DEBUG challenge not found, waiting for 1s     tries=3

Only Pebble read the mock's DNS, via -dnsserver. Everything the client does
with DNS — the authoritative-nameserver discovery, the retry loop, the advisory
timeout — was covered in its failure path only, and every order paid the full
wait for nothing.

Fix

The mock forwards what it does not own. A name outside its zones was
answered NOERROR with no records, which a resolver reads as an authoritative
"no such record" and does not retry elsewhere — so a client pointed here as its
only resolver would lose the other containers. Those questions now go upstream,
which is what makes it a resolver rather than only a CA's -dnsserver.

The gateways use it. One dns: entry per gateway service.

The mock says what it was asked. The check is advisory, so an order
succeeds whether or not it worked and nothing downstream reveals which. Every
question is logged and served at /api/dns-queries.

Cases

• Answered — for a record the suite published. Observed, not triggered: the
  periodic renewal picks a domain up as soon as it is added, so forcing one
  races it and can find nothing left to do.
• Asked repeatedly, never answered — for a name with no record. Polling is
  the point, and giving up must not stop the order.

Each keys off a name nothing else asks for, so they need no clearing and do not
depend on ordering.

Verification

Full suite, this branch vs its base, same host:

The two new passes are the two new cases; the 22 failures are identical and
pre-existing on this host, all in the proxy/TLS phases — the container resolver
inherits the host's search domain, so _dstack-app-address-wildcard.<name> is
looked up under it, and RA-TLS peering reports peer certificate does not contain app_id. Neither is touched here.

A self-check that resolves now settles in seconds instead of spending the whole
advisory wait, so the suite gets that time back on every order.

Base

Stacked on #1132, which is where the DNS-capable mock and the gateway suite's
use of it come from. Merge that first.